YSAMPLES
TOPIC
AUTHOR
ARG_PRO
ARG_CON
NOTES
 Round circles       J. Doe                                  These memos have been saved with a 57-character margin for YSAMPLE1.FMT                    Round circles       J. Doe                                  These memos have been saved with a 37-character margin for YSAMPLE2.FMT   
Essential to the flexibility of YAME is its capability to 
dynamically configure itself without leaving dBASE. This 
is achieved with tiered parameters. When invoked, YAME 
attempts to process four stages of parameters:
    (1) Default
    (2) .COM invocation
    (3) YAMEPARM
    (4) .BIN invocation
When run as a .COM, YAME will go through stages 1, 2, and 
3; for .BIN invocation, stages 1, 3, and 4. Some examples 
will make things clearer:
Let's say that you want to run YAME as your external memo 
editor, a .COM invocation. You want a margin of 50 for 
most of your memo fields. The default word wrap margin is 
65 characters. You add the following WP line to your 
CONFIG.DB file:
    WP = Y /m50
Every time you edit a memo, dBASE runs YAME. When YAME 
starts, it sets its margin to the default, 65. It then 
sees the parameter specified when it was run, a margin of 
50. That is the margin that is used.
If you then want a margin of 70 for a particular memo, 
you'll need to override the default margin of 65 and the 
margin of 50 specified on the WP line of the CONFIG.DB 
file. This is when YAMEPARM comes in. You CALL YAMEPARM 
with parameters that you want:
    call YAMEPARM with "/m70"
The next time YAME runs, it will set its default margin, 
then the margin of 50, and then see the parameter in 
YAMEPARM and use that. If you had another memo with a 
margin of 40, you'd:
    call YAMEPARM with "/m40"
and when you want to revert back to the WP parameters, 
you'd:
    call YAMEPARM
Parameters set up through YAMEPARM will stay in effect 
until different parameters are sent, or until you 
uninstall YAMEPARM by CALLing it with no parameters.
For a .BIN invocation, you'd use YAMEPARM to set your 
personal defaults:
    call YAMEPARM with "/m50"
From then on, every time you CALL Y, YAME will first set 
the margin to its default, 65, then see the margin in 
YAMEPARM and use that. If you then wanted a margin of 70, 
you'd include the margin parameter in the CALL:
    call Y with "/m70 MEMO_TMP.$DB"
If you ever want to go back to your personal default of 
50, leave out the margin parameter in the CALL to YAME:
    call Y with "MEMO_TMP.$DB"
And if you ever want to use YAME's default of 65, you can
    call YAMEPARM
to clear your personal default as well.
YAMEPARM and YAMEBUFF communicate with Y.COM by using one 
of the User Interrupt Vectors (Int 60h - 66h). Some of 
these vectors are used by other programs and drivers, but 
there are usually a few available.
YAMEPARM and YAMEBUFF each use their own vector, so if 
both of them are LOADed and installed, they use two 
vectors. If they are not uninstalled before they are 
RELEASEd and/or you QUIT dBASE, those vectors will not be 
cleared. Pretty soon, there will be no free vectors, and 
YAMEPARM and YAMEBUFF will fail.
Therefore, it is absolutely critical that you uninstall 
YAMEPARM and YAMEBUFF by CALLing them with no parameters 
before RELEASing them and/or QUITting dBASE. Again, IT IS 
ABSOLUTELY CRITICAL THAT YOU UNINSTALL YAMEPARM AND 
YAMEBUFF BY CALLING THEM WITH NO PARAMETERS BEFORE 
RELEASING THEM AND/OR QUITTING DBASE.
YAMEPARM will indicate successful installation by 
changing the first letter of the parameter string to a 
"T"; failure is indicated by an "F".  For example, the 
sequence
    cParm = "/@11,0,19,39 /bd"
    call YAMEPARM with cParm
will change the memory variable cParm to
    "T@11,0,19,39 /bd"
if YAMEPARM is installed successfully and
    "F@11,0,19,39 /bd"
if it is not. Once installed successfully, further CALLs 
to YAMEPARM should return "T", until of course YAMEPARM 
is RELEASEd or dBASE QUITs. Since the memory variable is 
changed, the original character, usually a "/", must be 
restored before using the parameter string again.
Note that every time you pass parameters to YAMEPARM, 
they stay memory resident. You do not have to CALL 
YAMEPARM before every single memo. You only need to use 
YAMEPARM when the parameters change.
YAMEBUFF operates in a similar manner. You CALL YAMEBUFF 
with the maximum file size you want to allow. This limit 
is enforced by the YAME program, and does not affect the 
amount of memory occupied by YAMEBUFF.BIN. YAMEBUFF.BIN 
is almost 64 KB in size; most of it, 63.5 KB or 65024 
bytes, is buffer space; the remainder is the YAMEBUFF 
installation code. Even if you
    call YAMEBUFF with 4000
to keep the memo fields below 4 KB, YAMEBUFF will still 
occupy 64 KB of memory. In these situations, you can use 
the smaller buffer file, YAMEBUF8.BIN, which has 8 KB 
(8192 bytes) of buffer space. YAMEBUF8 works exactly like 
YAMEBUFF, except that the maximum maximum is only 8 KB, 
not 63.5 KB. Do not have YAMEBUFF and YAMEBUF8 LOADed 
simulataneously.
YAMEBUFF (and YAMEBUF8) will return the amount of space 
that was registered as the maximum allowable file size. 
In most cases, this means that your parameter will be 
returned unchanged. The exceptions are:
    (1) You asked for more space than there was in the 
.BIN, i.e. more than 65024 for YAMEBUFF and 8192 for 
YAMEBUF8. In those cases, those limits will be registered 
and returned.
    (2) You asked for more than 65535 bytes. Don't do 
that.
    (3) YAMEBUFF was unable to install itself. In this 
case, YAMEBUFF will return 0. You should verify that the 
return value is greater than zero to make sure that 
YAMEBUFF was installed before your try to edit something.
If either YAMEPARM or YAMEBUFF return failure codes ("F" 
and 0, respectively), this means that there were no 
available vectors to hook into. This is because either 
you've already got a ton of gizmos loaded in your system, 
or, more likely, you forgot to uninstall YAMEPARM or 
YAMEBUFF before RELEASing them and/or QUITting dBASE. 
Remember that it is absolutely critical that you 
uninstall YAMEPARM and YAMEBUFF by CALLing them with no 
parameters before RELEASing them and/or QUITting dBASE.
Essential to the flexibility of YAME 
is its capability to dynamically 
configure itself without leaving 
dBASE. This is achieved with tiered 
parameters. When invoked, YAME 
attempts to process four stages of 
parameters:
    (1) Default
    (2) .COM invocation
    (3) YAMEPARM
    (4) .BIN invocation
When run as a .COM, YAME will go 
through stages 1, 2, and 3; for .BIN 
invocation, stages 1, 3, and 4. Some 
examples will make things clearer:
Let's say that you want to run YAME 
as your external memo editor, a .COM 
invocation. You want a margin of 50 
for most of your memo fields. The 
default word wrap margin is 65 
characters. You add the following WP 
line to your CONFIG.DB file:
    WP = Y /m50
Every time you edit a memo, dBASE 
runs YAME. When YAME starts, it sets 
its margin to the default, 65. It 
then sees the parameter specified 
when it was run, a margin of 50. That 
is the margin that is used.
If you then want a margin of 70 for a 
particular memo, you'll need to 
override the default margin of 65 and 
the margin of 50 specified on the WP 
line of the CONFIG.DB file. This is 
when YAMEPARM comes in. You CALL 
YAMEPARM with parameters that you 
want:
    call YAMEPARM with "/m70"
The next time YAME runs, it will set 
its default margin, then the margin 
of 50, and then see the parameter in 
YAMEPARM and use that. If you had 
another memo with a margin of 40, 
you'd:
    call YAMEPARM with "/m40"
and when you want to revert back to 
the WP parameters, you'd:
    call YAMEPARM
Parameters set up through YAMEPARM 
will stay in effect until different 
parameters are sent, or until you 
uninstall YAMEPARM by CALLing it with 
no parameters.
For a .BIN invocation, you'd use 
YAMEPARM to set your personal 
defaults:
    call YAMEPARM with "/m50"
From then on, every time you CALL Y, 
YAME will first set the margin to its 
default, 65, then see the margin in 
YAMEPARM and use that. If you then 
wanted a margin of 70, you'd include 
the margin parameter in the CALL:
    call Y with "/m70 MEMO_TMP.$DB"
If you ever want to go back to your 
personal default of 50, leave out the 
margin parameter in the CALL to YAME:
    call Y with "MEMO_TMP.$DB"
And if you ever want to use YAME's 
default of 65, you can
    call YAMEPARM
to clear your personal default as 
well.
YAMEPARM and YAMEBUFF communicate 
with Y.COM by using one of the User 
Interrupt Vectors (Int 60h - 66h). 
Some of these vectors are used by 
other programs and drivers, but there 
are usually a few available.
YAMEPARM and YAMEBUFF each use their 
own vector, so if both of them are 
LOADed and installed, they use two 
vectors. If they are not uninstalled 
before they are RELEASEd and/or you 
QUIT dBASE, those vectors will not be 
cleared. Pretty soon, there will be 
no free vectors, and YAMEPARM and 
YAMEBUFF will fail.
Therefore, it is absolutely critical 
that you uninstall YAMEPARM and 
YAMEBUFF by CALLing them with no 
parameters before RELEASing them 
and/or QUITting dBASE. Again, IT IS 
ABSOLUTELY CRITICAL THAT YOU 
UNINSTALL YAMEPARM AND YAMEBUFF BY 
CALLING THEM WITH NO PARAMETERS 
BEFORE RELEASING THEM AND/OR QUITTING 
DBASE.
YAMEPARM will indicate successful 
installation by changing the first 
letter of the parameter string to a 
"T"; failure is indicated by an "F".  
For example, the sequence
    cParm = "/@11,0,19,39 /bd"
    call YAMEPARM with cParm
will change the memory variable cParm 
    "T@11,0,19,39 /bd"
if YAMEPARM is installed successfully 
    "F@11,0,19,39 /bd"
if it is not. Once installed 
successfully, further CALLs to 
YAMEPARM should return "T", until of 
course YAMEPARM is RELEASEd or dBASE 
QUITs. Since the memory variable is 
changed, the original character, 
usually a "/", must be restored 
before using the parameter string 
again.
Note that every time you pass 
parameters to YAMEPARM, they stay 
memory resident. You do not have to 
CALL YAMEPARM before every single 
memo. You only need to use YAMEPARM 
when the parameters change.
YAMEBUFF operates in a similar 
manner. You CALL YAMEBUFF with the 
maximum file size you want to allow. 
This limit is enforced by the YAME 
program, and does not affect the 
amount of memory occupied by 
YAMEBUFF.BIN. YAMEBUFF.BIN is almost 
64 KB in size; most of it, 63.5 KB or 
65024 bytes, is buffer space; the 
remainder is the YAMEBUFF 
installation code. Even if you
    call YAMEBUFF with 4000
to keep the memo fields below 4 KB, 
YAMEBUFF will still occupy 64 KB of 
memory. In these situations, you can 
use the smaller buffer file, 
YAMEBUF8.BIN, which has 8 KB (8192 
bytes) of buffer space. YAMEBUF8 
works exactly like YAMEBUFF, except 
that the maximum maximum is only 8 
KB, not 63.5 KB. Do not have YAMEBUFF 
and YAMEBUF8 LOADed simulataneously.
YAMEBUFF (and YAMEBUF8) will return 
the amount of space that was 
registered as the maximum allowable 
file size. In most cases, this means 
that your parameter will be returned 
unchanged. The exceptions are:
    (1) You asked for more space than 
there was in the .BIN, i.e. more than 
65024 for YAMEBUFF and 8192 for 
YAMEBUF8. In those cases, those 
limits will be registered and 
returned.
    (2) You asked for more than 65535 
bytes. Don't do that.
    (3) YAMEBUFF was unable to 
install itself. In this case, 
YAMEBUFF will return 0. You should 
verify that the return value is 
greater than zero to make sure that 
YAMEBUFF was installed before your 
try to edit something.
If either YAMEPARM or YAMEBUFF return 
failure codes ("F" and 0, 
respectively), this means that there 
were no available vectors to hook 
into. This is because either you've 
already got a ton of gizmos loaded in 
your system, or, more likely, you 
forgot to uninstall YAMEPARM or 
YAMEBUFF before RELEASing them and/or 
QUITting dBASE. Remember that it is 
absolutely critical that you 
uninstall YAMEPARM and YAMEBUFF by 
CALLing them with no parameters 
before RELEASing them and/or QUITting 
dBASE.
Essential to the flexibility of YAME is its capability to dynamically configure itself without leaving dBASE. This is achieved with tiered parameters. When invoked, YAME attempts to process four stages of parameters:
    (1) Default
    (2) .COM invocation
    (3) YAMEPARM
    (4) .BIN invocation
When run as a .COM, YAME will go through stages 1, 2, and 3; for .BIN invocation, stages 1, 3, and 4. Some examples will make things clearer:
Let's say that you want to run YAME as your external memo editor, a .COM invocation. You want a margin of 50 for most of your memo fields. The default word wrap margin is 65 characters. You add the following WP line to your CONFIG.DB file:
    WP = Y /m50
Every time you edit a memo, dBASE runs YAME. When YAME starts, it sets its margin to the default, 65. It then sees the parameter specified when it was run, a margin of 50. That is the margin that is used.
If you then want a margin of 70 for a particular memo, you'll need to override the default margin of 65 and the margin of 50 specified on the WP line of the CONFIG.DB file. This is when YAMEPARM comes in. You CALL YAMEPARM with parameters that you want:
    call YAMEPARM with "/m70"
The next time YAME runs, it will set its default margin, then the margin of 50, and then see the parameter in YAMEPARM and use that. If you had another memo with a margin of 40, you'd:
    call YAMEPARM with "/m40"
and when you want to revert back to the WP parameters, you'd:
    call YAMEPARM
Parameters set up through YAMEPARM will stay in effect until different parameters are sent, or until you uninstall YAMEPARM by CALLing it with no parameters.
For a .BIN invocation, you'd use YAMEPARM to set your personal defaults:
    call YAMEPARM with "/m50"
From then on, every time you CALL Y, YAME will first set the margin to its default, 65, then see the margin in YAMEPARM and use that. If you then wanted a margin of 70, you'd include the margin parameter in the CALL:
    call Y with "/m70 MEMO_TMP.$DB"
If you ever want to go back to your personal default of 50, leave out the margin parameter in the CALL to YAME:
    call Y with "MEMO_TMP.$DB"
And if you ever want to use YAME's default of 65, you can
    call YAMEPARM
to clear your personal default as well.
YAMEPARM and YAMEBUFF communicate with Y.COM by using one of the User Interrupt Vectors (Int 60h - 66h). Some of these vectors are used by other programs and drivers, but there are usually a few available.
YAMEPARM and YAMEBUFF each use their own vector, so if both of them are LOADed and installed, they use two vectors. If they are not uninstalled before they are RELEASEd and/or you QUIT dBASE, those vectors will not be cleared. Pretty soon, there will be no free vectors, and YAMEPARM and YAMEBUFF will fail.
Therefore, it is absolutely critical that you uninstall YAMEPARM and YAMEBUFF by CALLing them with no parameters before RELEASing them and/or QUITting dBASE. Again, IT IS ABSOLUTELY CRITICAL THAT YOU UNINSTALL YAMEPARM AND YAMEBUFF BY CALLING THEM WITH NO PARAMETERS BEFORE RELEASING THEM AND/OR QUITTING DBASE.
YAMEPARM will indicate successful installation by changing the first letter of the parameter string to a "T"; failure is indicated by an "F".  For example, the sequence
    cParm = "/@11,0,19,39 /bd"
    call YAMEPARM with cParm
will change the memory variable cParm to
    "T@11,0,19,39 /bd"
if YAMEPARM is installed successfully and
    "F@11,0,19,39 /bd"
if it is not. Once installed successfully, further CALLs to YAMEPARM should return "T", until of course YAMEPARM is RELEASEd or dBASE QUITs. Since the memory variable is changed, the original character, usually a "/", must be restored before using the parameter string again.
Note that every time you pass parameters to YAMEPARM, they stay memory resident. You do not have to CALL YAMEPARM before every single memo. You only need to use YAMEPARM when the parameters change.
YAMEBUFF operates in a similar manner. You CALL YAMEBUFF with the maximum file size you want to allow. This limit is enforced by the YAME program, and does not affect the amount of memory occupied by YAMEBUFF.BIN. YAMEBUFF.BIN is almost 64 KB in size; most of it, 63.5 KB or 65024 bytes, is buffer space; the remainder is the YAMEBUFF installation code. Even if you
    call YAMEBUFF with 4000
to keep the memo fields below 4 KB, YAMEBUFF will still occupy 64 KB of memory. In these situations, you can use the smaller buffer file, YAMEBUF8.BIN, which has 8 KB (8192 bytes) of buffer space. YAMEBUF8 works exactly like YAMEBUFF, except that the maximum maximum is only 8 KB, not 63.5 KB. Do not have YAMEBUFF and YAMEBUF8 LOADed simulataneously.
YAMEBUFF (and YAMEBUF8) will return the amount of space that was registered as the maximum allowable file size. In most cases, this means that your parameter will be returned unchanged. The exceptions are:
    (1) You asked for more space than there was in the .BIN, i.e. more than 65024 for YAMEBUFF and 8192 for YAMEBUF8. In those cases, those limits will be registered and returned.
    (2) You asked for more than 65535 bytes. Don't do that.
    (3) YAMEBUFF was unable to install itself. In this case, YAMEBUFF will return 0. You should verify that the return value is greater than zero to make sure that YAMEBUFF was installed before your try to edit something.
If either YAMEPARM or YAMEBUFF return failure codes ("F" and 0, respectively), this means that there were no available vectors to hook into. This is because either you've already got a ton of gizmos loaded in your system, or, more likely, you forgot to uninstall YAMEPARM or YAMEBUFF before RELEASing them and/or QUITting dBASE. Remember that it is absolutely critical that you uninstall YAMEPARM and YAMEBUFF by CALLing them with no parameters before RELEASing them and/or QUITting dBASE.
Essential to the flexibility of YAME 
is its capability to dynamically 
configure itself without leaving 
dBASE. This is achieved with tiered 
parameters. When invoked, YAME 
attempts to process four stages of 
parameters:
    (1) Default
    (2) .COM invocation
    (3) YAMEPARM
    (4) .BIN invocation
When run as a .COM, YAME will go 
through stages 1, 2, and 3; for .BIN 
invocation, stages 1, 3, and 4. Some 
examples will make things clearer:
Let's say that you want to run YAME 
as your external memo editor, a .COM 
invocation. You want a margin of 50 
for most of your memo fields. The 
default word wrap margin is 65 
characters. You add the following WP 
line to your CONFIG.DB file:
    WP = Y /m50
Every time you edit a memo, dBASE 
runs YAME. When YAME starts, it sets 
its margin to the default, 65. It 
then sees the parameter specified 
when it was run, a margin of 50. That 
is the margin that is used.
If you then want a margin of 70 for a 
particular memo, you'll need to 
override the default margin of 65 and 
the margin of 50 specified on the WP 
line of the CONFIG.DB file. This is 
when YAMEPARM comes in. You CALL 
YAMEPARM with parameters that you 
want:
    call YAMEPARM with "/m70"
The next time YAME runs, it will set 
its default margin, then the margin 
of 50, and then see the parameter in 
YAMEPARM and use that. If you had 
another memo with a margin of 40, 
you'd:
    call YAMEPARM with "/m40"
and when you want to revert back to 
the WP parameters, you'd:
    call YAMEPARM
Parameters set up through YAMEPARM 
will stay in effect until different 
parameters are sent, or until you 
uninstall YAMEPARM by CALLing it with 
no parameters.
For a .BIN invocation, you'd use 
YAMEPARM to set your personal 
defaults:
    call YAMEPARM with "/m50"
From then on, every time you CALL Y, 
YAME will first set the margin to its 
default, 65, then see the margin in 
YAMEPARM and use that. If you then 
wanted a margin of 70, you'd include 
the margin parameter in the CALL:
    call Y with "/m70 MEMO_TMP.$DB"
If you ever want to go back to your 
personal default of 50, leave out the 
margin parameter in the CALL to YAME:
    call Y with "MEMO_TMP.$DB"
And if you ever want to use YAME's 
default of 65, you can
    call YAMEPARM
to clear your personal default as 
well.
YAMEPARM and YAMEBUFF communicate 
with Y.COM by using one of the User 
Interrupt Vectors (Int 60h - 66h). 
Some of these vectors are used by 
other programs and drivers, but there 
are usually a few available.
YAMEPARM and YAMEBUFF each use their 
own vector, so if both of them are 
LOADed and installed, they use two 
vectors. If they are not uninstalled 
before they are RELEASEd and/or you 
QUIT dBASE, those vectors will not be 
cleared. Pretty soon, there will be 
no free vectors, and YAMEPARM and 
YAMEBUFF will fail.
Therefore, it is absolutely critical 
that you uninstall YAMEPARM and 
YAMEBUFF by CALLing them with no 
parameters before RELEASing them 
and/or QUITting dBASE. Again, IT IS 
ABSOLUTELY CRITICAL THAT YOU 
UNINSTALL YAMEPARM AND YAMEBUFF BY 
CALLING THEM WITH NO PARAMETERS 
BEFORE RELEASING THEM AND/OR QUITTING 
DBASE.
YAMEPARM will indicate successful 
installation by changing the first 
letter of the parameter string to a 
"T"; failure is indicated by an "F".  
For example, the sequence
    cParm = "/@11,0,19,39 /bd"
    call YAMEPARM with cParm
will change the memory variable cParm 
    "T@11,0,19,39 /bd"
if YAMEPARM is installed successfully 
    "F@11,0,19,39 /bd"
if it is not. Once installed 
successfully, further CALLs to 
YAMEPARM should return "T", until of 
course YAMEPARM is RELEASEd or dBASE 
QUITs. Since the memory variable is 
changed, the original character, 
usually a "/", must be restored 
before using the parameter string 
again.
Note that every time you pass 
parameters to YAMEPARM, they stay 
memory resident. You do not have to 
CALL YAMEPARM before every single 
memo. You only need to use YAMEPARM 
when the parameters change.
YAMEBUFF operates in a similar 
manner. You CALL YAMEBUFF with the 
maximum file size you want to allow. 
This limit is enforced by the YAME 
program, and does not affect the 
amount of memory occupied by 
YAMEBUFF.BIN. YAMEBUFF.BIN is almost 
64 KB in size; most of it, 63.5 KB or 
65024 bytes, is buffer space; the 
remainder is the YAMEBUFF 
installation code. Even if you
    call YAMEBUFF with 4000
to keep the memo fields below 4 KB, 
YAMEBUFF will still occupy 64 KB of 
memory. In these situations, you can 
use the smaller buffer file, 
YAMEBUF8.BIN, which has 8 KB (8192 
bytes) of buffer space. YAMEBUF8 
works exactly like YAMEBUFF, except 
that the maximum maximum is only 8 
KB, not 63.5 KB. Do not have YAMEBUFF 
and YAMEBUF8 LOADed simulataneously.
YAMEBUFF (and YAMEBUF8) will return 
the amount of space that was 
registered as the maximum allowable 
file size. In most cases, this means 
that your parameter will be returned 
unchanged. The exceptions are:
    (1) You asked for more space than 
there was in the .BIN, i.e. more than 
65024 for YAMEBUFF and 8192 for 
YAMEBUF8. In those cases, those 
limits will be registered and 
returned.
    (2) You asked for more than 65535 
bytes. Don't do that.
    (3) YAMEBUFF was unable to 
install itself. In this case, 
YAMEBUFF will return 0. You should 
verify that the return value is 
greater than zero to make sure that 
YAMEBUFF was installed before your 
try to edit something.
If either YAMEPARM or YAMEBUFF return 
failure codes ("F" and 0, 
respectively), this means that there 
were no available vectors to hook 
into. This is because either you've 
already got a ton of gizmos loaded in 
your system, or, more likely, you 
forgot to uninstall YAMEPARM or 
YAMEBUFF before RELEASing them and/or 
QUITting dBASE. Remember that it is 
absolutely critical that you 
uninstall YAMEPARM and YAMEBUFF by 
CALLing them with no parameters 
before RELEASing them and/or QUITting 
dBASE.